Uber数据基础架构现在及未来
优步是全球领先的移动互联网创业公司,通过创新科技为乘客和合作司机高效即时匹配,提供安全、高效、可靠、便利的出行选择，他的使命是“使出行如自来水一样可靠，每个人在任何地方都能享用”。为了履行这一承诺，优步依赖于在每个层面做出数据驱动的决策。
优步目前的业务广泛分布于75个国家或地区，超过500个城市，基于分析可以充分了解一个城市人们出行的特点(热点区域、主要交通流向等)。大部分的决策都得益于更快的数据处理能力，其底层核心在于构建了强大的Hadoop大规模数据处理平台。下面对Hadoop在优步的发展过程做一个初步介绍。
2014年以前数据架构比较简单，数据主要有日志和DB数据组成，采集到数据仓库后再做进一步加工，然后直接服务商业应用或即席查询分析等，架构如下：
此架构的中心是一个数据仓库，用于将各种数据源收归一处，经统一建模处理后再提供服务给上层业务或数据分析人员使用。传统的数据仓库建设可初略分为3个环节，数据采集、维度建模、数据服务。
首先简要介绍数据采集过程中的技术，分为两类：
日志采集与处理方案较多，下面对常见的做一个对比：
Scribe | Chukwa | Kafka | Flume | |
公司 | apache/yahoo | Cloudera | ||
开源时间 | 2008年10月 | 2009年11月 | 2010年12月 | 2009年7月 |
实现语言 | C/C++ | JAVA | SCALA | JAVA |
框架 | push/push | push/push | push/pull | push/pull |
容错性 | collector和store之间有容错机制，而agent和collector之间的容错需要用户自己实现 | agent定期记录已送给collector的数据偏移量，一旦出现故障后，可根据偏移量继续发送数据。 | agent可用通过collector自动识别机制获取可用collector。store自己保存已经获取数据的偏移量，当collector故障后可根据偏移量继续获取数据。 | agent和collector,collector和store之间均有容错机制，且提供了三种级别的可靠性保证 |
负载均衡 | 无 | 无 | 使用zookeeper | 使用zookeeper |
扩展性 | 好 | 好 | 好 | 好 |
agent | Thrift client,需自己实现 | 自带一些agent,如获取Hadoop logs的agent | 用户需根据kafka提供的low-level和high-level API自己实现 | 提供了各种非常丰富的agent |
collector | thrift server | - | 使用sendfile,zero-copy等技术提高性能 | 系统提供了很多collector，可直接使用 |
store | HDFS | HDFS | HDFS | HDFS |
总结 | 设计简单，易于使用，但容错和负载均衡方面不够好，且资料较少。 | 属于Hadoop系列产品，直接支持Hadoop，目前版本升级比较快，但还有待完善。 | 设计架构非常巧妙，适合异构集群，但产品较新，其稳定性有待验证。 | 非常优秀 |
由此可见，优步选择kafka的原因也就一目了然。
DB数据采集
在数据加载到数据库的过程中，分为全量加载（更新）和增量加载（更新）。全量加载是首先全表删除后再从源表进行数据加载的方式；增量加载是目标表仅更新源表变化的数据。常用的方式有：
系统日志分析方式
触发器方式
时间戳方式
全表比对方式
源系统增量（delta）数据直接或者转换后加载。
优步在数据处理方面选用了部分amazon的云计算解决方案，采用AmazonS3，它具有简单的Web 服务接口，可用于在 Web 上的任何位置存储和检索任意数量的数据。它能够提供99.999999999% 的持久性，并且可以在全球大规模传递数万亿对象。可作为分析的批量存储库或“数据湖”。
另外数据在存储到 S3 中后，会自动采用成本更低、存储期限更长的云存储类进行存档。计算方面采用了Amazon EMR，它是可用于运行 AWS上托管的 Hadoop 群集，各完成多种类型的数据加工处理任务。
数据建模是专门用于分析型数据库、数据仓库、数据集市建模的方法，除了在数据库中常见的ER建模和关系建模，还包括专门针对数据仓库的维度建模技术，包括几种模型：星形模型、雪花模型、混合模型。
2015年前的优步从服务器数量、计算任务量、数据量等几个方面来看Hadoop规模仍然较小。由于其业务高速发展，到如今已经有非常大的变化，由上千台服务器组建的Hadoop集群，每天处理10W+计算任务，PB级的数据存储，数据处理框架不仅采用spark，同时hive和Presto也广泛应用。新架构与2014年相比，最大的变化在于计算和存储引擎的统一，规模现实大幅度增涨。
Hadoop集群规模从2014年初期的几个节点，到2015年增长到百余节点和PB级数据容量，2016年发展到千余节点，预计2017年可发展到5000节点、100PB存储的规模。
在集群规模和业务高速发展的过程中，优步解决了一些自身面临的个性化需求，包括：
Strict Schema Management：由于大量使用数据的人员主要通过SQL来加工数据，而SQL允许用户在高层的数据结构上工作，所有SQL语句都接受集合作为输入，返回集合作为输出，因此需要严格、统一管理数据的结构信息或数据模型。
多种大数据处理工具协同：面向不同类型的数据用户提供多种数据处理工具，如Hive、Presto、Spark等，普通用户可直接使用hive/presto完成常规的数据处理与分析，利用spark可完成更深入的数据挖掘与图计算等。
随着优步业务的全球化拓展，对应的服务与底层的计算与存储引擎也需要有全球化的能力，资源的全球化管理也将成为重中之重，下面简要介绍几个资源管理框架的特点与应用。
YARN | MESOS |
Single Level Scheduler | Two Level Scheduler |
Use C groups for isolation | Use C groups for Isolation |
CPU, Memory as a resource | CPU, Memory and Disk as a resource |
Works well with Hadoop work loads | Works well with longer running services |
YARN support time based reservations | Mesos does not have support of reservations |
Dominant resource scheduling | Scheduling is done by frameworks and depends on case to case basis |
Mesos和YARN之间的主要区别围绕着优先级的设计以及调度任务的方式。Mesos的设计初衷是作为整个数据中心的一个可拓展的全局资源管理器。YARN出于管理Hadoop规模的需求。在YARN出现之前，资源管理(功能)集成在Hadoop MapReduce V1架构中，为了有助于MapReduce的扩展而将其移除(转移到YARN中实现)。MapReduce的Job Tracker并不能在超过上千台的机器中有效调度MapReduce任务。YARN在下一代Hadoop生命周期中被创造，主要围绕着资源拓展。
Mesos的调度策略，Mesos决定了哪些资源可用，它把分配请求返回给一个应用调度器(应用调度器和执行器被称作“框架”)。这些分配请求被框架接受或者拒绝。这个模型被认为是非单体模型，因为它是一个“两级”调度器，调度算法是可拔插的。
Mesos允许任何实现任何调度算法，每个算法都能根据自己的策略进行接收或是拒绝分配请求，并且可以容纳成千上万种调度程序以多租户的方式运行在同一个集群。
Mesos的两级调度模型允许每个框架(自己)决定使用哪种算法来调度运行的工作。Mesos扮演仲裁者，在多个调度器上来调度资源，解决冲突，并且确保资源基于业务策略被公平地分发。分配请求到来时，框架会执行任务来消费那些提供的资源。或者框架可以选择拒绝请求并且等待下一个分配请求。多年的操作系统和分布式系统的实践发展证明，这种模型的好处在于它具有良好的扩展性。它已被Google和Twitter证明。
YARN的调度策略，当job请求到达YARN资源管理器，YARN评估所有可用的资源然后调度job。YARN以一种整体的方式，直接决定job运行的位置。在MapReduce架构演变的过程中，重申强调YARN的出现十分重要。
在Hadoop任务的资源规模伸缩需求的驱动下，YARN把资源管理的模型从MR的Job Tracker中独立出来，在Resources Manager组件中实现。YARN既不是为长时间运行的服务而设计，也不是为满足短期交互/快速响应式请求(像简短而快速的Spark任务)，尽管它可能调度其他种类的工作任务，但这并不是一个理想的模型。
MapReduce的资源需求、执行模型和架构需求不同于长时间运行的服务，如Web服务器、SOA应用程序或是像Spark和Storm那样的实时任务。同时，YARN为了易于无状态的脚本任务重启而设计。它并不能处理像分布式文件系统或数据库那样的有状态的服务。然而YARN的整体的调度器理论上可以处理不同类型的工作负载(通过把新的算法合并到调度代码)，对于支持日益复杂的调度算法，这并不是一个轻量级的模型。
当你把如何管理数据中心作为整体来评估时，一方面使用Mesos来管理数据中心的所有资源，另一方面使用YARN来安全的管理Hadoop任务，但它并不具有管理整个数据中心的能力。数据中心运营商倾向于把集群划分为的不同区域(Hadoop集群和非Hadoop集群)来应对这两个场景。在同一个数据中心使用Mesos和YARN，为了受益于资源管理器，目前需要创建两个静态分区。此时意味着当指定资源被Hadoop的YARN管理时，Mesos就无法起作用。这也许过于简化了，尽管这么做确实有效。但本质上，我们是想避免这种情况。
能否让企业和数据中心受益于YARN和Mesos的协调工作?答案是肯定的。一些著名的公司——eBay、MapR和Mesosphere共同合作了一个项目叫做Myriad。这个开源软件项目既是一个Mesos框架，又是一个YARN调度器，这就使得Mesos能够管理YARN的资源请求。当一个任务到达YARN时，它会通过Myriad调度器调度它，使请求与Mesos提供的资源匹配。
相应的，Mesos也会将它传递给Mesos工作节点。之后，这个Mesos节点会把这个请求与一个正在执行YARN节点的管理器的Myriad执行器关联。Myriad在Mesos资源启动YARN节点管理器，启动之后，Mesos资源会告诉YARN资源管理器哪些资源可用。这时YARN就可以随意地使用这些资源。Myriad为Mesos的可用资源池和YARN的任务(需要用到Mesos中资源)之间架起了一座无缝连接的桥梁。
优步在 Mesos 上设计了全新统一资源调度系统Peloton，用来更有效和弹性地管理计算资源，并且为不同团队提供了分层的的最大最小公平算法，不久的将来可能开源。
内容参考：Hadoop Infrastructure @Uber Past , Present and Future ppt及网络公开资料
专访刘昕博士：深度学习与人工智能
王公仆ArchData峰会（北京）精彩内容抢先看！9月24日
关键词：AI、区块链、大数据、智能运维、深度学习!!!